Method and System to Verify the Identity of a User

ABSTRACT

A method and system to verify the identity of a user are described. The system may include a communications module to receive a billing telephone number and a private data segment associated with a user; an address detector to obtain a street address associated with the user; a private data processor to obtain one or more identification records, utilizing the obtained street address and the private data segment; and a matching module to compare the one or more identification records with the private data segment associated with the user to generate a match result.

RELATED APPLICATIONS

This application is a continuation application of and claims priority toU.S. patent application Ser. No. 13/549,270 filed on Jul. 13, 2012,which claims priority to U.S. patent application Ser. No. 11/655,647filed on Jan. 18, 2007, and is hereby incorporated by reference in itsentirety.

TECHNICAL FIELD

This application relates to a method and system to verify the identityof a user.

BACKGROUND

While electronic commerce (e-commerce) marketplace may provide apowerful online platform for the sale of goods and services by acommunity of individuals and small businesses, online fraud remains asource of significant concern. As consumers continue to demand astreamlined experience online, they may become frustrated byinstructions to disclose private financial information at every point ofpurchase. Some existing verification approaches rely on requiring a userto initiate a telephone call to a transaction processing facility or torespond to an inbound call with an authorization code. These methods maynot always be convenient for users.

BRIEF DESCRIPTION OF DRAWINGS

Embodiments of the present invention are illustrated by way of exampleand not limitation in the figures of the accompanying drawings, in whichlike reference numbers indicate similar elements and in which:

FIG. 1 is a diagrammatic representation of a network environment withinwhich an example embodiment may be implemented;

FIG. 2 is a block diagram of a system to verify the identity of a user,in accordance with an example embodiment;

FIG. 3 a flow chart of a method to verify the identity of a user, inaccordance with an example embodiment;

FIG. 4 is a sequence diagram illustrating an identity verificationsystem being utilized in conjunction with a subscriber line validationprocess, in accordance with an example embodiment; and

FIG. 5 is a diagrammatic representation of an example data structure torepresent an identity verification request, in accordance with anexample embodiment; and

FIG. 6 is a diagrammatic representation of an example machine in theform of a computer system within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed.

DETAILED DESCRIPTION

The method to verify the identity of a user (or to authenticate a user)and an identity verification system (IVS) are described. In the contextof the electronic commerce (e-commerce) marketplace, IVS may be utilizedadvantageously to reduce online fraud by providing merchants with a toolto confirm the identity of a user who is attempting to complete anonline purchase for a digital good or service. The identity verificationsystem, in one example embodiment, is configured to offer a high degreeof confidence to the merchant of a consumer's identity while minimizingthe stress for the consumer. In one example embodiment, user's identityis be verified using self-reported data elements that include personaldata associated with the user that is not publicly available, e.g., thelast four or all nine digits of the user's social security number (SSN),an eight digit date of birth, a portion of the user's driver's licensenumber, a certified electronic mail (email) address, etc. An item ofpersonal data of the user that is not publicly available, or a portionof such private data, may be referred to as a private data segment of auser. The self-reported data elements may be utilized, in one exampleembodiment, to confirm that the user has a relationship to the chosenpayment instrument, e.g., that the user is in control of the billingtelephone number (BTN) in a scenario where the user selected a phonebill as the payment method.

Identity verification system, in one example embodiment, may be utilizedadvantageously with alternative payment options including electroniccheck, direct invoicing, credit card or other card-alternative paymentmethods. The method and system to verify the identity of a user may beimplemented in the context of a network environment. An example networkenvironment 100 is illustrated in FIG. 1.

As shown in FIG. 1, the network environment 100 may include a usersystem (e.g., a system associated with a consumer or a merchant) 110 anda network-based transaction facility 120. The user system 110 may run abrowser application 112 and may have access to the network-basedtransaction facility 120 via a communications network 130. Thecommunications network 130 may be a public network (e.g., the Internet,a wireless network, etc.) or a private network (e.g., LAN, WAN,Intranet, etc.).

A user may utilize the browser 112 running on the user system 110 toaccess services provided by the network-based transaction facility 120.One of the services provided by the network-based transaction facility120 is an identity verification system 122. The identity verificationsystem 122 may be configured to receive a billing telephone number and apersonal data segment associated with a user and, based on thisinformation, determine whether the user can be successfullyauthenticated. The facility 120 may also host a system to provide tousers (e.g., to merchants) a payment method verification service (notshown) that may be utilized in conjunction with the identityverification system 122, as described further below with reference toFIG. 4. The identity verification system 122 may be configured toutilize services that are located remotely with respect to thenetwork-based transaction facility 120. Such external services mayinclude, for example, a street address service 142 that may be hosted bya third party provider system 140, and a personal data matching service152 that may be hosted by a third party provider system 150. An exampleidentity verification system may be described with reference to FIG. 2.

FIG. 2 is a block diagram of an example identity verification system200, in accordance with one example embodiment. The example identityverification system 200 may include a communications module 210, anaddress detector 220, a private data processor 230, a matching module240, a business rules engine 250, and an authentication responsegenerator 260. The example identity verification system 200 may alsoinclude a billing number validation interface 280 to facilitateutilization of the identity verification system 200 in conjunction witha subscriber line validation system. It will be noted that, in someexample embodiment, the identity verification system 200 may include oneor more modules to provide an interface with other payment verificationsystems in addition to or instead of the billing number validationinterface 280. Some examples of other payment verification systemsinclude a credit card verification system, a mobile phone validationinterface, an automatic clearinghouse (ACH), etc.

The communications module 210 may be configured to receive, from aclient (e.g., a merchant requesting the identity verification system 200to verify the identity of a user) a billing telephone number and aprivate data segment associated with a user who is the subject of anidentity verification request. As mentioned above, a private datasegment associated with a user may include various items of personalinformation associated with the user that is not publicly available. Aprivate data segment may include, for example, some or all of the digitsof the social security number of a user, short message service (SMS)information, customer code, out of wallet type questions (e.g., theuser's date of birth, the user's driver's license number, etc.), voicecapture, electronic Letter of Agency (eLOA), a certified email, and anassociation of the user's Internet protocol (IP) address With the user'sstreet address.

The address detector 220 may be configured to forward the billingtelephone number information to a third party provider (e.g., to thethird party provider 140 hosting a street address service 142) and toobtain a street address associated with the billing telephone number.The private data processor 230 may be utilized to forward the obtainedstreet address to another third party provider (e.g., to the third partyprovider 150 hosting the personal data matching service 152) along withthe private data segment associated with the user and to obtain inresponse one or more identification records associated with the streetaddress and the private data segment. In one example embodiment, theprivate data processor 230 is configured to accept from a third partyprovider a predetermined maximum number of identification records thathave been determined to most closely match the street address and theprivate data segment. The personal data matching service 152 may alsocommunicate to the private data processor 230 that there are no recordsavailable that sufficiently match the provided street address and theprivate data segment.

The matching module 240, in one example embodiment, may be configured tocompare the identification records (if any) obtained from the personaldata matching service 152 with the data segment associated with the userto generate a match result. The business rules engine 250 may beutilized in cooperation with the matching module 240 to determinewhether the match result corresponds to a positive authentication of theuser or to a negative (or failed) authentication. For example, where theprivate segment data is the last four digits of the user's socialsecurity number, a match result including an exact match of the streetaddress and a partial match of the last four digits of the user's socialsecurity number (e.g., three out of four matching digits) may beidentified by the matching module 240 as an acceptable match that shouldresult in a positive authentication of the user. In another exampleembodiment, the business rules engine 250 may be configured to requirean exact match between the private data segment received from the userand the data exhibited in an identification record provided by thepersonal data matching service 152. The authentication criteria utilizedby the matching module 240 and the business rules engine 250 may beconfigurable, e.g., by utilizing a configuration module 270, based on aprofile of a client (e.g., a merchant) who is requesting the identity ofa user to be verified. The profiles may be stored in a client profilesdatabase 272.

The match result generated by the matching module 240 may be utilized bythe authentication response generator 260 to generate an authenticationmessage based on the match result. In some example embodiments, if t thematching module 240 generated a match result indicative of a failedauthentication of the user, the communications module (or another moduleconfigured to perform such function) may automatically initiate analternative identity verification procedure. An alternative identityverification procedure may include, for example, automaticallyinitiating a telephone call to the billing telephone number orrequesting the user to initiate a telephone call to a telephone numberassociated with the network-based transaction facility 120 of FIG. 1. Anexample method to verify the identity of a user can be described withreference to FIG. 3.

FIG. 3 is a flow chart of a method 300 to verify the identity of a user,according to one example embodiment. The method 300 may be performed byprocessing logic that may comprise hardware (e.g., dedicated logic,programmable logic, microcode, etc.), software (such as run on a generalpurpose computer system or a dedicated machine), or a combination ofboth. In one example embodiment, the processing logic resides at theidentity verification system 200 illustrated in FIG. 2. The method 300may be performed by the various modules discussed above with referenceto FIG. 2. Each of these modules may comprise processing logic.

As shown in FIG. 3, at operation 302, the communications module 210 ofthe identity verification system 200 receives a billing telephone numberand a private data segment associated with a user. The billing telephonenumber is forwarded to a third party provider in order for the addressdetector 220 to obtain, at operation 304, a street address associatedwith the billing telephone number. The private data processor 230forwards the obtained street address to another third party providerhosting a personal data matching service (e.g., the personal datamatching service 152 of FIG. 1) in order to obtain, at operation 306,one or more identification records. In one example embodiment, theidentity verification system 200 may be configured to permit apredetermined maximum number of identification records to be received byprivate data processor 230 from the personal data matching service 152.Each of the received identification records may be associated with thestreet address obtained by the address detector 220.

If the address detector 220 fails to obtain the street addressassociated with the billing telephone number, a message may be sent backto the business rules engine 250 to automatically initiate another,alternative, identity verification method, e.g., via initiating atelephone call to the user or via receiving a telephone call from theuser.

It will be noted that, in some example embodiments, the street addressmay be provided to the identity verification system 200 via thecommunications module 210, e.g., from a merchant requesting to verifythe identity of the user. The operation 304 of obtaining the streetaddress from a third party may be then omitted. Instead, the streetaddress received by the communications module 210 may be forwarded to athird party provider hosting a personal data matching service to obtainone or more identification records.

At operation 308, the matching module 240 compares the identificationrecords obtained from the personal data matching service 152 with thedata segment associated with the user in order to generate a matchresult. If it is determined, at operation 310, that the generated matchresult corresponds to a positive authentication of the user (the matchresult is acceptable), the authentication response generator generatesan authentication message including an indication of a positiveauthentication of the user, at operation 312. If it is determined, atoperation 310, that the generated match result corresponds to a negativeor a failed authentication of the user (the match result is notacceptable), the authentication response generator generates anauthentication message including an indication of a negativeauthentication of the user, at operation 314. At operation 316, theauthentication message is communicated to a merchant who is the sourceof the initial authentication request.

In some example embodiments, if the matching module 240 fails to obtainany identification records the personal data matching service 152 or ifthe generated match result corresponds to a failed authentication of theuser, a message may be sent to the business rules engine 250 toautomatically initiate another, alternative, identity verificationmethod, e.g., via initiating a telephone call to the user or viareceiving a telephone call from the user.

As mentioned above, example method and system to verify the identity ofa user described with reference to FIG. 2 and FIG. 3 may be utilizedadvantageously with a payment method verification service. A paymentmethod verification service, in one example embodiment, may beimplemented as a subscriber line validation system. A subscriber linemay be a telephone line or the like, which a consumer or a business mayobtain from a telephone company, a local exchange carrier (LEC), or aMobile Operator. Line data, e.g., a billing telephone number (BTN), maybe used to validate the subscriber line. The BTN may be used toinvestigate various databases in order to obtain an indication of thecredit worthiness of the subscriber account associated with thesubscriber line.

A subscriber line validation system may include an application programinterface (API) connected to a vendor or service provider (collectivelyreferred to as a merchant). A merchant may request the validation of thesubscriber line prior to concluding an electronic transaction with asubscriber (e.g., a consumer or a business) via the subscriber line. Itis, however, to be appreciated that the API may be connected to avariety of different hosts or clients which require validation of asubscriber line via which the merchant may carry out transactions forgoods and/or services.

In one exemplary embodiment, a subscriber line validation system isconnected to a plurality of merchants which conduct transactions withusers via line termination equipment such as a telephone, a personalcomputer or the like. Such merchants, when conducting transactions, maypreferably charge a user for their services by adding such charges to atelephone account of the user rather than charging the goods and/orservices to a credit card, debit card, or the like. Accordingly, thevalidation of the subscriber line, and the subscriber account associatedwith the subscriber line, may be of benefit to the merchant prior tocompleting a transaction. The validation may include determining whetheror not the subscriber line associated with the billing telephone numberis a billable line and, accordingly, the subscriber account associatedwith the subscriber line may thus be billed for the transaction.

In one exemplary embodiment, a merchant communicates a request to thesystem and forwards the billing telephone number to the network-basedtransaction facility that hosts a subscriber line validation system. Thesubscriber line validation system then processes the informationreceived from the merchant and provides a validation status, e.g. a codeindicating that the subscriber line number is a valid billable number ora code indicating that the subscriber line number is not a validbillable number.

The subscriber line validation system may include a comparator module, athreshold database, an OFFNET database, an ONNET database, a competitivelocal exchange carrier (CLEC) database, a 42 BLOCK database, a block andcancel database, an unbilled and/or unpaid bills database, lineidentification database (LIDB), a validity check module, a regionalaccount office (RAO) database, an operating company number (OCN)database, an ONNET database, an address verification database, acustomer account record exchange (CARE) results database, an AutomaticNumber Identification (ANI) watch database, and an NPA (Numbering PlanArea) exchange database. It is to be appreciated that, in lesssophisticated embodiments, all of the above databases need not beincluded. However, for enhanced accuracy, all of the above databases maybe included. Further databases may also be included to further enhancethe reliability of the validation process.

In addition to any one or more of the above databases, the subscriberline validation system may be in communication via a conventionalcommunication channel with an off-site or, in some embodiments, on-siteline identification database (LIDB) host. The LIDB host may include aline number portability (LNP) database. In one exemplary embodiment, theLNP database may have a front end access to a plurality of LIDBs. TheLNP database may however be a separate database. An example subscriberline validation system may communicate the subscriber line number to theLIDB host, which, in turn, may communicate reference subscriber data(e.g., in a form of LIDB codes) back to the subscriber line validationsystem for processing. The subscriber line validation system may thenprocess the LIDB codes to provide the merchant with validation datarelating to the subscriber line. The subscriber line validation systemmay be used to identify telephone numbers being served by CLECs in orderto ensure that calls are routed correctly on ported lines.

Broadly, the subscriber line validation system may have a variety ofdifferent components, including a communications module, and a processormodule. The a processor module includes the various databases, thecomparator module, the validity check module, and an interrogationmodule for interrogating the LIDB host. It is to be appreciated that theaforementioned modules may be defined by one or more servers withassociated databases. The LIDB host may comprise many different LIDBdatabases maintained by various LECs and, accordingly, may bedistributed among various different geographic locations.

Referring in particular to FIG. 4 of the drawings, a sequence diagram isshown illustrating providing to a merchant verification of the identityof a user in conjunction with a validation of a subscriber line. In oneexemplary embodiment, a consumer 402 provides payment information to amerchant 404 (operation 1) along with a transaction authorizationrequest. The merchant 404 initiates a request to a business access point406 to validate a subscriber line and to verify the identity of theconsumer 402 (operation 2).

As shown in FIG. 4, operations 3 through 18 are directed to thesubscriber line validation based on the billing telephone numberprovided by the merchant 404 to the business access point 406. Thebusiness access point 406 provides the billing telephone number to asubscriber line validation system 408 (operation 3). The subscriber linevalidation system 408 first determines whether the subscriber line isassociated with an Automatic Number Identification (ANI). In the exampleof FIG. 4 the billing telephone number provided by the merchant 404 isassociated with ANI (operation 4).

It will be noted that the business access point 406 and the subscriberline validation system 408 may be associated with a single businessentity, e.g., a business entity that is in control of the network-basedtransaction facility 120 of FIG. 1. The business access point 406requests the subscriber line validation system 408 to interrogate itsOFFNET database (operation 5) in order to determine whether the industrystandard NPA/NXX and operating company number (OCN) of the subscriberline is present in the OFFNET database. The OFFNET database includes NPA/NXX and OCN combinations of operating companies, with which theproprietor or user of the subscriber line validation system 408 does nothave billing and collection agreements to bill into the telephonecompany's bill page associated with the subscriber line. Accordingly,the proprietor or user of the subscriber line validation system isunable to include a charge in the account associated with the subscriberline on behalf of the merchant for the transaction carried out with themerchant via the subscriber line.

If the line number is in the OFFNET database, then the processor moduleof the subscriber line validation system 408 generates an indicationthat the NPA/NXX and OCN for the subscriber line number are notbillable. The response associated with the interrogation of the OFFNETdatabase is communicated to the business access point 406 (operation 6).

Thereafter, the business access point 406 requests the subscriber linevalidation system 408 to interrogate the CLEC database (operation 7) todetermine whether the line number is found in a known CLEC table in theCLEC database. CLEC numbers are those line numbers that are known tohave ported to a CLEC and, accordingly, the proprietor of the subscriberline validation system is thus unable to route these line numbers to thecorrect billing entities. If the line number is found in the CLECdatabase, then the processor module generates a code indicating that theline number is not billable for the CLEC and thus the transaction cannotbe charged to the subscriber account associated with the subscriberline. The response associated with the interrogation of the CLECdatabase is communicated to the business access point 406 (operation 8).

The business access point 406 requests the subscriber line validationsystem 408 to interrogate the LEC BLOCK database (operation 9) todetermine whether the subscriber of the line number has requested abilling block. The response associated with the interrogation of the LECBLOCK database is communicated to the business access point 406(operation 10). The business access point 406 requests the subscriberline validation system 408 to interrogate the BLOCK and CANCEL database(operation 11) to determine whether the subscriber of the line numberhas requested that a service be cancelled or blocked from furtherbilling. The response associated with the interrogation of the BLOCK andCANCEL database is communicated to the business access point 406(operation 12).

Next, the business access point 406 requests the subscriber linevalidation system 408 to determine (operation 13) whether the billingtelephone number is a business telephone number. The response associatedwith this determination is communicated to the business access point 406(operation 14). The business access point 406 requests the subscriberline validation system 408 to interrogate the UNBILLS database(operation 15) to determine whether the billing telephone number isassociated with any unpaid bills. The response associated with theinterrogation of the UNBILLS database is communicated to the businessaccess point 406 (operation 16).

The processing described in the abovementioned operations may beutilized to conduct a preliminary investigation into the subscriber linenumber or ANI to provide an initial indication of whether or not the ANIcorresponds with a billable subscriber line. Once the initialinvestigation has been conducted, in certain embodiments, the subscriberline validation system then uses the ANI to obtain reference subscriberline data in the form of LIDB codes from one or more industry standarddatabases, e.g. the LIDB host. The business access point 406 requestsexternal services 410 to interrogate the LIDB database or host(operation 17). The response associated with the interrogation of theLIDB database or host is communicated to the business access point 406(operation 18). The business access point 406 requests the subscriberline validation system 408 to interrogate the ONNET database (operation19). The ONNET database provides the merchant/client and productspecific billable information. A subscriber line number may be billablefor certain products. The ONNET database looks at the specific clientsthat have been approved by each NPA/NXX and OCN and the products thatthey have been approved to bill. The response associated with theinterrogation of the ONNET database is communicated to the businessaccess point 406 (operation 20).

As shown in FIG. 4, operations 21 through 25 are directed to validationof the identity of a user based on the billing telephone number and thelast four digits of a social security number provided by the merchant404 to the business access point 406. The business access point 406initiates a request to external services 410 to obtain street addressinformation associated with the billing telephone number (operation 21).The street address information is communicated back to the businessaccess point 406 (operation 22). The business access point 406 providesthe obtained street address and the last four digits of a socialsecurity number provided by the merchant 404 to external services 410(operation 23). In response, the external services 410 provide aresponse indicating whether any identification records match the streetaddress and the last four digits of a social security number (operation24).

The business access point 406 performs matching operations, as discussedwith reference to FIG. 3, and communicates a response to the merchant404 (operation 25), based on the outcome of the matching operations. Theresponse may include an indication of a positive authentication of theuser or an indication of a failed authentication of the user. Themerchant 404 may then communicate to the consumer 402 a positive or anegative response to the user's transaction authorization request(operation 26).

FIG. 5 is a diagrammatic representation of an example data structure 500to represent an identity verification request that may be utilized bythe identity verification system 200 of FIG. 2, in accordance with anexample embodiment. As shown in FIG. 5, the example data structure 500comprises fields 502 through 512.

“REQUEST_TRANSACTION.ACCTID” field 502 is used to represent accountidentification information associated with the client (e.g., a merchantor a consumer). “REQUEST TRANSACTION.CLIENT ID” field 504 is used torepresent an identification number assigned to the client by theidentity verification service. “REQUEST TRANSACTION.BTN” field 506 isused to represent the billing telephone number provided by the client.“REQUEST_TRANSACTION.BTN_VAL” field 508 is used to indicate whether thesubscriber line associated with the billing telephone number is to bevalidated in addition to validation the identity of a user.

“REQUEST TRANSACTION.L4SSN” field 510 is used to represent the last fourdigits of the user's social security number.“REQUESTTRANSACTION.ADDR_RULE” field 512 is used to indicate a rule tobe utilized for street address detection.

It will be noted, that an identity verification system request, as wellas other information utilized by the identity verification system 200 ofFIG. 2, may be represented utilizing a variety of techniques that may beavailable to a person skilled in the art.

FIG. 6 shows a diagrammatic representation of a machine in the exampleform of a computer system 600 within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed. In alternative embodiments, themachine operates as a stand-alone device or may be connected (e.g.,networked) to other machines. In a networked deployment, the machine mayoperate in the capacity of a server or a client machine in server-clientnetwork environment, or as a peer machine in a peer-to-peer (ordistributed) network environment. The machine may be a personal computer(PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant(PDA), a cellular telephone, a web appliance, a network router, switchor bridge, or any machine capable of executing a set of instructions(sequential or otherwise) that specify actions to be taken by thatmachine. Further, while only a single machine is illustrated, the term“machine” shall also be taken to include any collection of machines thatindividually or jointly execute a set (or multiple sets) of instructionsto perform any one or more of the methodologies discussed herein.

The example computer system 600 includes a processor 602 (e.g., acentral processing unit (CPU), a graphics processing unit (GPU) orboth), a main memory 604 and a static memory 606, which communicate witheach other via a bus 608. The computer system 600 may further include avideo display unit 610 (e.g., a liquid crystal display (LCD) or acathode ray tube (CRT)). The computer system 600 also includes analpha-numeric input device 612 (e.g., a keyboard), a user interface (UI)navigation device 614 (e.g., a cursor control device), a disk drive unit616, a signal generation device 618 (e.g., a speaker) and a networkinterface device 620.

The disk drive unit 616 includes a machine-readable medium 622 on whichis stored one or more sets of instructions and data structures (e.g.,software 624) embodying or utilized by any one or more of themethodologies or functions described herein. The software 624 may alsoreside, completely or at least partially, within the main memory 604and/or within the processor 602 during execution thereof by the computersystem 600, the main memory 604 and the processor 602 also constitutingmachine-readable media.

The software 624 may further be transmitted or received over a network626 via the network interface device 620 utilizing any one of a numberof well-known transfer protocols (e.g., Hyper Text Transfer Protocol(HTTP)).

While the machine-readable medium 622 is shown in an example embodimentto be a single medium, the term “machine-readable medium” should betaken to include a single medium or multiple media (e.g., a centralizedor distributed database, and/or associated caches and servers) thatstore the one or more sets of instructions. The term “machine-readablemedium” shall also be taken to include any medium that is capable ofstoring, encoding or carrying a set of instructions for execution by themachine and that cause the machine to perform any one or more of themethodologies of embodiments of the present invention, or that iscapable of storing, encoding or carrying data structures utilized by orassociated with such a set of instructions. The term “machine-readablemedium” shall accordingly be taken to include, but not be limited to,solid-state memories, optical and magnetic media, and carrier wavesignals. Such media may also include, without limitation, hard disks,floppy disks, flash memory cards, digital video disks, random accessmemory (RAMs), read only memory (ROMs), and the like.

The embodiments described herein may be implemented in an operatingenvironment comprising software installed on a computer, in hardware, orin a combination of software and hardware.

Thus, a method and system to verify the identity of a user have beendescribed. Although embodiments have been described with reference tospecific example embodiments, it will be evident that variousmodifications and changes may be made to these embodiments withoutdeparting from the broader spirit and scope of the inventive subjectmatter. Accordingly, the specification and drawings are to be regardedin an illustrative rather than a restrictive sense.

1. An identity verification system provided to verify the identity of auser associated with a phone bill that can be used as a payment method,the system comprising: a processor; and memory to store instructionswhich cause the processor to implement: a communications module toreceive, at a verification computer system, a billing telephone numberand a user-supplied private data segment, wherein the billing telephonenumber indicates that a user has selected an associated phone bill as apayment method; a private data processing module to obtain, from apersonal data computer system, one or more identification records; and amatching module to compare the one or more identification recordsobtained from the personal data computer system with the user-suppliedprivate data segment to generate a match result, the address servicecomputer system and the personal data computer system being third partycomputer systems.
 2. The system of claim 1, wherein the private datasegment comprises at least one of a date, a zip code, and a portion ofan address.
 3. The system of claim 1, wherein the memory also storesinstructions which cause the processor to implement a subscriber lineverification module to determine whether the particular phone bill maybe used to make purchases from third party merchants.
 4. The system ofclaim 1, further comprising a business rules engine to determine whetherthe match result corresponds to a positive authentication of the user.5. The system of claim 4, wherein the business rules engine is incommunication with a configuration module, the configuration moduleconfigured to identify authentication criteria.
 6. The system of claim5, wherein the authentication criteria comprises a partial match.
 7. Thesystem of claim 1, further comprising an authentication responsegenerator to generate an authentication message based on the matchresult.
 8. The system of claim 7, wherein the authentication message isindicative of positive authentication, the positive authentication beingbased on a partial match of a record from the one or more identificationrecords with the data segment corresponding to the date of birth of theuser.
 9. The system of claim 7, wherein the authentication message isindicative of a failed authentication.
 10. The system of claim 9,wherein the communications module is configured to initiate analternative identity verification procedure in response to the failedauthentication.
 11. The system of claim 10, wherein the alternativeidentity verification procedure comprises initiating a telephone call tothe billing telephone number.
 12. The system of claim 1, furtherincluding a billing number validation interface to obtain validation ofa telephone line account associated with the billing telephone number asa valid payment method for the user.
 13. The system of claim 1, whereinthe address detector is to obtain the street address associated with theuser from a third party provider, utilizing the billing telephonenumber.
 14. The system of claim 1, wherein the communications module isto receive the street address associated with the user and communicatethe street address associated with the user to the private dataprocessor.
 15. A machine-readable non-transitory storage medium havinginstruction data provided to verify the identity of a user associatedwith a phone bill that can be used as a payment method, wherein theinstruction data, when executed by a machine to cause the machine to:receive, at a verification computer system, a billing telephone numberand a private data segment, the user-supplied private data segmentcorresponding to a date of birth of a user, wherein the billingtelephone number indicates that a user has selected an associated phonebill as a payment method; obtain a street address associated with theuser; obtain one or more identification records, utilizing the obtainedstreet address; and compare the one or more identification records withthe user-supplied private data segment corresponding to the date ofbirth of the user to generate a match result
 16. An identityverification system provided to determine whether a user is authorizedto charge a purchase to a particular phone bill that can be used as apayment method, the system comprising: a communications module toreceive a billing telephone number and a user-supplied private datasegment, wherein the billing telephone number indicates that a user hasselected a particular phone bill as a payment method; a subscriber lineverification module to determine whether the particular phone bill maybe used to make purchases from third party merchants; a personal dataprocessing module to obtain a lookup result from a database of clientprofiles in response to the subscriber line verification moduledetermining that the particular phone bill may be used to make purchasesfrom third party merchants; and a matching module to compare theuser-supplied private data segment to the lookup result; anauthentication response generator to provide an authentication result inresponse to the comparison by the matching module.
 17. The identityverification system of claim 16, wherein the user-supplied private datasegment includes at least one of a portion of a social security number,a street address, a zip code, a postal code, a password, an accountnumber associated with the billing telephone number, and a date.
 18. Theidentity verification system of claim 16, wherein authentication resultis one of an indication that the user is authorized to charge a purchaseto the particular phone bill, an indication that the user is notauthorized to charge a purchase to the particular phone bill, and anindication that further user-supplied private data is needed to completea purchase.
 19. The identity verification system of claim 16, furthercomprising a transactions module to charge the particular phone billwith a purchase in response to the authentication response generatorproviding a response indicating that the user is authorized to chargethe purchase to the particular phone bill.